Automated test equipment (ATE) can be any testing assembly that performs a test on a semiconductor device or electronic assembly. ATE assemblies may be used to execute automated tests that quickly perform measurements and generate test results that can then be analyzed. An ATE assembly may be anything from a computer system coupled to a meter, to a complicated automated test assembly that may include a custom, dedicated computer control system and many different test instruments that are capable of automatically testing electronics parts and/or semiconductor wafer testing, such as system-on-chip (SOC) testing or integrated circuit testing. ATE systems both reduce the amount of time spent on testing devices to ensure that the device functions as designed and serve as a diagnostic tool to determine the presence of faulty components within a given device before it reaches the consumer.
FIG. 1 is a schematic block diagram of a conventional automatic test equipment body 100 for testing certain typical DUTs, e.g. a semiconductor memory device such as a DRAM. The ATE includes an ATE body 100 with hardware bus adapter sockets 110A-110N. Hardware bus adapter cards 110A-110N specific to a particular communication protocol e.g. PCIe, USB, SATA, SAS etc., connect to the hardware bus adapter sockets provided on the ATE body and interface with the DUTs via cables specific to the respective protocol. The ATE body 100 also includes a tester processor 101 with an associated memory 108 to control the hardware components built into the ATE body 100 and to generate the commands and data necessary to communicate with the DUTs being tested through the hardware bus adapter cards. The tester processor 101 communicates with the hardware bus adapter cards over system bus 130. The tester processor may be programmed to include certain functional blocks including a pattern generator 102 and a comparator 106. Alternatively, the pattern generator 102 and comparator 106 may be hardware components mounted on an expansion or adapter card that plug into the ATE body 100.
The ATE body 100 tests the electrical functions of the DUTs 112A-112N connected to the ATE body 100 through hardware bus adapters plugged into the hardware bus adapter sockets of the ATE body 100. Accordingly, the tester processor 101 is programmed to communicate test programs to the DUTs using the protocol unique to the hardware bus adapters. Meanwhile, the other hardware components built into the ATE body 100 communicate signals with each other and with the DUTs according to test programs operating in the tester processor 101.
The test program run by the tester processor 101 may include a function test which involves writing input signals created by the pattern generator 102 to the DUTs, reading out the written signals from the DUTs and using the comparator 106 to compare the output with the expected patterns. If the output does not match the input, the tester processor 101 will identify the DUT as being defective. For example, if the DUT is a memory device such as a DRAM, the test program will write data generated by the pattern generator 102 to the DUT using a Write Operation, read data from the DRAM using a Read Operation and compare the expected bit pattern with the read pattern using the comparator 106.
In conventional systems, the tester processor 101 needs to contain the functional logic blocks to generate the commands and test patterns used in testing the DUTs, such as the pattern generator 102 and the comparator 106, programmed in software directly on the processor. However, in some instances certain functional blocks such as the comparator 106 may be implemented on a field programmable gate array (FPGA), which is an application specific integrated circuit (ASIC) type semiconductor device that can program logic circuits according to a user's demand.
The FPGAs used in conventional systems rely on the tester processor 101 to transfer the commands and test patterns to the FPGA, which the FPGA in turn relays over to the DUTs. Because the tester processor, and not the FPGA, is responsible for generating the commands and test patterns, the number and type of DUTs that can be tested with a given ATE body is limited by the processing capabilities and programming of the tester processor. Where the tester processor generates all the commands and test patterns, bandwidth constraints on the system bus 130 connecting the tester processor to the various hardware components, including any FPGA devices and hardware bus adapter sockets, also places an upper limit on the number of DUTs that can tested simultaneously.
Also, in conventional systems, the communication protocol used to communicate with the DUTs is fixed because the hardware bus adapter cards that plug into the ATE body 100 are single purpose devices that are designed to communicate in only one protocol and cannot, generally, be reprogrammed to communicate in a different protocol. For example, an ATE body configured to test PCIe devices will have hardware bus adapter cards plugged into the body that support only the PCIe protocol. In order to test DUTs supporting a different protocol, e.g., Universal Flash Storage (UFS), the user would ordinarily need to replace the PCIe hardware bus adapter cards with bus adapter cards supporting the UFS protocol. Unless the PCIe hardware bus adapter cards are physically substituted with cards supporting the other protocol, such a system can only test DUTs that support the PCIe protocol. Thus, on the test floor, critical time is consumed replacing hardware bus adapter cards when DUTs running a different protocol from the one that the existing adapter cards support need to be tested.
Another drawback of current tester systems is that most off-the-shelf FPGA systems are not configured to provide native support for UFS protocols. The UFS protocol is a high-speed communication protocol between a Host Controller and a memory device. The key benefit of the UFS protocol is that it consumes less power than other protocols, e.g., PCIe. To reduce power usage, the UFS protocol supports varying speed modes (including high speed gears and low speed gears) and also certain power saving states. However, supporting the different speed gears (or different speed modes) and power saving states in the UFS specification requires special accommodations in the hardware. UFS is not currently as widely adopted as PCIe and, therefore, off-the-shelf FPGAs do not natively support all the various modes (including the low speed gears and certain power saving states) specified in the UFS specification. Accordingly, conventional ATE systems that use FPGAs to communicate with DUTs are not able to adequately test DUTs that are UFS-compliant.